In order to achieve access independence and to maintain a smooth interoperation with wired terminals across the Internet, the IMS as specified e.g. in the 3GPP (3rd Generation Partnership Project) specification PS 23.228 has been developed to be conformant to IETF (Internet Engineering Task Force) “Internet Standards”. The IP multimedia core network (IM CN) subsystem enables network operators of mobile or cellular networks to offer their subscribers multimedia services based on and built upon Internet applications, services and protocols. The intention is to develop such services by mobile network operators and other 3rd party suppliers including those in the Internet space using the mechanisms provided by the Internet and the IM CN subsystem. The IMS thus enables conversion of, and access to, voice, video, messaging, data and web-based technologies for wireless users, and combines the growth of the Internet with the growth in mobile communications.
FIG. 1 shows an architecture of an IMS network according to the above 3GPP specification. The architecture is based on the principle that the service control for home subscribed services for a roaming subscriber is in the home network HN, e.g. a Serving Call State Control Function (S-CSCF) 10 is located in the home network HN.
In general, the S-CSCF 10 performs the session control service for served terminal devices, e.g. mobile terminals or user equipments (UEs). It maintains a session state as needed by the network operator for support of the services. Within an operator's network, different S-CSCFs may have different functionalities. The functions performed by the S-CSCF 10 during a respective session are e.g. registration, session flow management, charging and resource utilization management. When a subscriber roams to a visited network VN, the visited network VN supports a Proxy-CSCF (P-CSCF) 30 which enables the session control to be passed to the S-CSCF 10 located at the home network HN and providing the service control. Furthermore, an Interrogating-CSCF (I-CSCF) 50 is provided in the home network HN as a contact point within the operators network for all connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area. There maybe multiple I-CSCFs within an operator's network. The functions performed by the I-CSCF 50 include assigning an S-CSCF, e.g. the S-CSCF 10, to a user performing a registration procedure, routing a request received from another network towards an S-CSCF, obtaining the address of an S-CSCF from a subscriber data base, e.g. a Home Subscriber Server (HSS) 20 as shown in FIG. 1, and/or forwarding requests or responses to an S-CSCF determined based on the address obtained from the HSS 20.
The P-CSCF 30 is the first contact point within the IMS. Its address is discovered by a terminal device, e.g. a first terminal device (UE 1) 40 or a second terminal device (UE 2) 60 shown in FIG. 1, following a PDP (Packet Data Protocol) context activation. The P-CSCF 30 behaves like a proxy, i.e. it accepts requests and services them internally or forwards them on, possibly after translation. The P-CSCF 30 may also behave as a User Agent (UA), i.e. in abnormal conditions it may terminate and independently generate transactions. A UA is an interface between a user and a network application. For example, for web applications, the UA may be a browser. The functions performed by the P-CSCF 30 are forwarding register requests received from a UE to an I-CSCF, e.g. the I-CSCF 50, determined using the home domain name as provided by the respective UE, and forwarding requests or responses to the respective UE.
As regards the provision of a secure access to the IMS, the P-CSCF 30 is arranged to maintain a security association (SA) between itself and each UE, as defined in the 3GPP specification TS 33.203. Furthermore, the P-CSCF 30 provides security towards the S-CSCF 10 by security methods defined in the 3GPP specification TS 33.210.
Further details regarding the functions of the different CSCF elements shown in FIG. 1 can be gathered from the above mentioned 3GPP specifications.
A protocol used for exchanging messages in the IMS is the Session Initiation Protocol (SIP) as defined in the IETF specification RFC 2543. A SIP message is either a request from a client to a server, or a response from a server to a client. Both request and response messages use a generic message format specified in the IETF specification RFC 822 for transferring entities, i.e. the body of the message.
There are various identities that may be associated with a user of IP multimedia services. Every subscriber of the IMS has a private user identity (IM Private Identity (IMPI)) assigned by the home network operator, and used, for example, for registration, authorization, administration, and accounting purposes. However, the IMPI is not used for routing SIP messages. It is contained in all registration requests (including re-registration and de-registration requests) passed from a UE to the home network HN. The IMPI is securely stored at the UE and cannot be modified at the UE. The IMPI is used to identify the user's information stored within the HSS 20 and is authenticated only during registration of the subscriber. Thus, the HSS 20 and the S-CSCF 10 need to obtain and store the IMPI. Furthermore, a subscriber of the IMS may have one or more public user identities (IM Public Identities (IMPU)) which are used by any user for requesting communications to other users. These IMPUs may be included e.g. on a business card. Both telephone numbers and Internet naming schemes can be used to address users depending on their IMPUs. The IMPUs may take the form of a SIP URL (Uniform Resource Locator) or E.164 numbers. The IMPU may be used to identify the user's information within the HSS 20, for example during mobile terminated session setup.
SIP messages between a UE and the P-CSCF 30 are integrity protected. This integrity protection also provides message origin authentication. The authenticated origin may be identified by any identity to which an integrity key has been explicitly or implicitly bound in the registration procedure. These identities include the IMPI and the registered IMPUs. However, a fraudulent user may use an integrity key bound to a registered IMPU to generate a correct message authentication code on a SIP message, e.g. SIP INVITE, but include the IMPU of another subscriber in the SIP message. This would lead to a number of threats, e.g. the S-CSCF 10 would then charge the session to the wrong IMPU. As a result, UEs have the capability to send messages that appear to come from a particular UE but in fact come from another. The primary cause of this problem is due to the hop-by-hop security model combined with the lack of complete information either the P-CSCF 30 has on what is allowed in messages or the S-CSCF 10 has on where the message actually came from. Further details regarding the above fraudulent user attack can be gathered from the 3GPP specification TSG WG 3 Security S3-010633. The main problem arises from the fact that IMPUs may be invisibly registered. Hence, the P-CSCF 30 cannot bind integrity keys to those IMPUs.
Thus, the questions are which identities are bound to the integrity key transferred by a registration procedure message and how does the P-CSCF 30 inform the S-CSCF 10 about an identity bound to the integrity key used to verify the integrity of a message received from a user agent (UA) of a UE.
In the 3GPP specification TSG SA WG3 Security S3-010673, possible solutions to the above problems have been suggested. According to a first solution, the S-CSCF 10 sends the integrity key and all IMPUs for which a user is registered (explicitly or implicitly) to the P-CSCF 30 in the registration procedure message. Whenever the P-CSCF 30 later checks the integrity of a SIP message from a UE, using the integrity key, it checks whether any IMPU in the SIP message is one of those received with the integrity key in the registration procedure message. As an alternative, according to a second solution, when the P-CSCF 30 verifies a SIP message from the UE using the integrity key, it adds the IMPI received with the integrity key in the registration procedure message before forwarding the message to the S-CSCF 10. The S-CSCF 10 then checks whether the IMPI corresponds to the IMPU in the received message. Finally, according to a third solution, the UA of the UE adds the IMPI to the protected part of any integrity protected SIP message. The P-CSCF 30 then verifies the integrity of that message using the integrity key and checks whether the IMPI is one which was received with the integrity key in the registration procedure message. Again, the S-CSCF 10 then checks whether the IMPI corresponds to the IMPU in the received message.
However, according to the above suggested solutions, implicitly registered IMPU(s) are needed to be send to the P-CSCF 30 in the first solution. Furthermore, the P-CSCF 30 needs to know the IMPI in the second solution. To achieve this, additional fields might have to be added to the SIP messages. An additional field might also have to be added to the SIP message in the third solution. Thus, substantial modifications of the messages and signaling procedures are required.